Changing Hashcodes: Objects, Intialisation, and Collections

Java requires objects’ hashcodes to be consistent with object equality, and to change only when an object’s equality changes. Equality dependent Java collections impose a stricter contextual contract on an objects’ equality, comparability, and hashcode methods: that they cannot change while those objects are in collections. By dynamically profiling 30 Java applications, we have determined that programmers use quite sophisticated techniques to ensure their objects meet these contracts. Some objects are immutable; some objects are initially mutable, but become immutable when inserted into equalitydependent collections; some objects continue to change when inserted into equality dependent collections — but those changes do not affect equality or hashcodes. On the other hand, some objects inserted into collections that do not depend on object equality, hashcodes, or comparisons will contine to change all their state, including equality and hashcode, while they are in those collections. Programmers and educators can use these results to ensure they (or their students) are aware of these subtle conditional contracts underlying Java’s collection design. These results can also guide language designers adding support for collections, relations, or equality: in particular; while immutablility suffices for many cases, it does not cover all of them.